OpenEdge Development:<br />Progress Dynamics Basic Development Security structures

Security structures are the what of the security system. They are application functionality you need to control in different ways, depending on the user. Each business security rule you want to create will associate users to structures within Progress Dynamics. Here are the structures you can define security on:

Action — Conceptually, actions are an abstraction for controlling visual objects in your application. For example, perhaps you want to restrict access to a particular tab in a tab folder window. Other possible targets include menu items and toolbar buttons. Actions also include some built in actions (Add, Cancel, Copy, Delete, Modify, View). Security on these actions in particular context automatically prevent built-in framework behavior from providing access. For example, if you could normally double-click a browse row to bring up an update window, a restricted user would get a message and be able to see the update window in view-only mode. The structure can be set universally or at the product module level.

Container — Containers are your main UI application objects, and the security system is already aware of all containers. There is no need to create an abstract structure in the security system to represent them. Associate users with containers and effectively revoke or grant access to all the application functionality in the container.

Data — Data security structures represent application-level security of your database records. Since database records are represented with the application as entities, data security is entity security. The security system is aware of application entities, so you do not need to create an abstract structure in the Security Control tool to represent them. Data security does not come with preprogrammed behavior. You must program the behavior that you require when a user has a data security allocation.

Data range — Data range structures are purely abstract codes you create in the Security Control tool to represent a data range that you want to modify depending on the user. When you associate the code with users, you specify the specific object, instance attribute, and from-to values. Data range security does not come with automatic behavior; you must program the behavior that you require when a user has data range security allocations.

Field — Field security structures identify database fields and application widgets you want to define additional security on. Normally, you define field-level security through your SDOs and SBOs (what is visible and what is not). Use field security when you want to vary your normal security by login company, for example. When you define a field security structure it applies globally across your application. You can narrow the restriction anyway you like when you define the structure. When you associate a field security structure with users, you specify the type of restriction (Full Access, Read Only, or Hidden).

Login company — While a login company conceptually represents an organizational entity, and thus an aggregation of users, it functions more as a security structure than as a user type. Think of login companies as structures that groups and users are granted or restricted access to. Login companies, in effect, are the primary security structure because each security rule you create requires you to specify one or all login companies as part of the rule.

Menu item — Any item appearing on a menu or toolbar. The security system is aware of all menu items, so there is no need to define an abstract security structure to represent them in the Security Control tool.

Menu structure — Any collection of menu items, called bands in Progress Dynamics, that can appear on a menu or toolbar. The security system is aware of all bands, so there is no need to define an abstract security structure to represent them in the Security Control tool.